Ascertaining domain contexts can be useful for a number of reasons. For example, cross domain security issues can arise when a script (i.e. software code) executes in the wrong domain. Scripts can execute in the wrong domain for reasons that include, among others, architectural flaws in an application's code path. Cross domain exploits can allow malicious code to access and manipulate information that would otherwise be unavailable to the code.
One type of application that can be susceptible to cross domain exploits is the web browser. In this context, consider the following. When a browser application browses to a web page, that particular web page can host other web pages and objects within it. That is, the web page can retrieve content from other web sites for use in conjunction with the web page. For example, an image or some other object on or associated with a web page may be downloaded from a web site which is different from the site from which the web page itself is downloaded. One of the problems with this scenario, as will be appreciated by the skilled artisan, is that while the site from which the web page is downloaded may be considered as “safe”, the site from which the image or object is downloaded may not be safe and, in fact, may constitute a rogue web site.
What can happen as a result of this situation is that rogue content may maliciously attempt to interact with the web page with which it is associated, or with content presented in other windows that are open on the user's computer. For example, a rogue object may attempt to capture user information (as by recording the user's keystrokes) and provide the information to an unauthorized entity or person.
Other cross domain boundary issues can arise from third party code or controls that are designed to execute in connection with an application. Again, in the context of a browser application, consider the following. When a web browser receives HTML content for a particular web page, the HTML may include code that identifies data that is intended to be processed by a third party control such as, for example, an ActiveX control, a browser helper object, or some other pluggable component. The browser application then typically takes steps to activate or instantiate the appropriate control and makes the data available for the control to process and render. One problem with this scenario, however, is that such controls and other third party code do not typically have to provide the application—in this case the browser application—with its domain context—that is, the context of the domain in connection with which the control or code is supposed to be running. By knowing the domain context associated with a particular control or piece of third party code, an intelligent decision could be made by the application as to whether to allow the control or code to execute. However, by not knowing the domain associated with the control or code, any such informed decision cannot be made.